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Abstract 

We briefly present a rule-based framework, called 
Eagle, shown to be capable of defining and implement- 
ing finite trace monitoring logics, including future and past 
time temporal logic, extended regular expressions, real-time 
and metric temporal logics (MTL), interval logics, forms of 
quantified temporal logics, and so on. In this paper we focus 
on a linear temporal logic (LTL) specialisation of Eagle. 
For an initial formula of size m, we establish upper bounds 
of O(m~2 m logm) and 0(m x T? m log^m) for the space and 
time complexity, respectively, of single step evaluation over 
an input trace. This bound is close to the lower bound 
0( 2v™) for future-time LTL presented in [18]. EAGLE has 
been successfully used, in both LTL and metric LTL forms, 
to test a real-time controller of an experimental NASA plan- 
etary rover. 

1. Introduction 

Linear temporal logic (LTL) [17] is now widely used for 
expressing properties of concurrent and reactive systems. 
Associated, production quality, verification tools have been 
developed, most notably based on model-checking tech- 
nology, and have enjoyed much success when applied to 
relatively small-scale models. Tremendous advances have 
been made in combating the combinatoric state space explo- 
sion inherent with data and concurrency in model checking, 
however, there remain serious limitations for its application 
to full-scale models and to software. This has encouraged a 
shift in the way model checking techniques are being ap- 
plied, from full state space coverage to bounded use for 
sophisticated testing, or debugging, and from static appli- 
cation to dynamic, or runtime, application. Our work on 
Eagle concerns this latter direction. 
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In runtime verification a software component, an ob- 
server, monitors the execution of a program and checks its 
conformity with a requirement specification. Runtime ver- 
ification can be applied to evaluate automatically test runs, 
either on-line or off-line, analyzing stored execution traces; 
or it can be used on-line during operation. Several runtime 
verification systems have been developed, of which some 
were presented at three recent international workshops on 
runtime verification [1]. Also a wide variety of specialised 
logics, largely based on LTL, have been proposed, see for 
example, [6, 7, 9, 8, 16, 15, 12, 11, 10]. This wide va- 
riety of logics caused us to search for a compact but gen- 
eral framework for defining monitoring logics, which would 
be powerful enough to capture essentially all of the above 
described logics, and more. Much influenced by our ear- 
lier work on executable temporal logic MetateM, see for 
example [3], the logic Eagle was the result In [5], we 
showed the richness and expressivity of Eagle, described 
an algorithm to synthesize monitors for Eagle and com- 
mented on an implementation of the framework in Java and 
some initial experiments. However, we found that the effi- 
ciency and complexity analysis of the general Eagle mon- 
itoring algorithm is difficult and can be shown to be depen- 
dent on both the length of the trace and the size of the initial 
formula in the worst case. In this paper, we thus investigate 
the complexity and practical effectiveness of a specialised 
version of the monitoring algorithm for the case of LTL con- 
taining a fixed number of past and future time temporal op- 
erators embedded as rales in EAGLE. We outline an effec- 
tive implementation of the monitoring algorithm and prove 
that its space and time complexity is exponential in the size 
of the formula and which is independent of the length of 
the trace for single step evaluation. This makes it scalable 
in terms of space as we do not store the trace either explic- 
itly or implicitly. S imil ar work was done in a rewriting 
framework for the case of future time LTL in [11]; how- 
ever, there the complexity of the monitoring was not clear 
as it was dependent on the strategy used by the rewrite en- 
gine for rewriting. The work in [12] addresses a monitoring 
algorithm for past time LTL only. 



The paper is structured as follows. Section 2 introduces 
our logic framework Eagle and then specializes it to LTL. 
In section 3 we discuss the monitoring algori thm and cal- 
culus with an illustrative example. This underlies our im- 
plementation for the special case of LTL, which is briefly 
described in section 4 where complexity bounds for the im- 
plementation can also be found. Section 5 describes an 
experiment performed using EaGLE, and shows how cyclic 
deadlock potentials can be detected with Eagle. Section 6 
states conclusion and future work. 

2 Eagle and Linear Temporal Logic 

Eagle [5] offers a succinct but powerful set of primitives, 
essentially supporting recursive parameterized equations, 
with a minimal/maximal fix-point semantics together with 
three temporal operators: next-time, previous-time, and 
concatenation. The parametrization of rules supports rea- 
soning about data values as well as the embedding of real- 
time, metric and statistical temporal logics. In Section 2. 1 
we motivate the fundamental concepts of Eagle through 
some simple examples drawn from LTL before presenting 
its formal definition. Then, in Section 2.2 we present a full 
embedding of LTL in Eagle and establish its correctness. 


complete this very brief introduction to Eagle suppose one 
wished to monitor the following property of a Java program 
state containing two variables jc and y: “ whenever we reach 
a stale where x — k > 0 for some value k, then eventually 
we will reach a state at which y === k”. In a linear temporal 
logic augmented with first order quantification, we would 
write: 0(x > 0 — y 3k.(k = x A Oy = k)). The parametriza- 
tion mechanism of Eagle allows data as well as formulas 
as parameters and are able to encode the above as: 

min R(im k) = Sometime(y == k ) 

mon M -- Always (x > 0 — » R (x ) ) 

The definition starting with keyword mon specifies the 
Eagle formula to be monitored. The rule R is parame- 
terized with an integer k; it is instantiated in the monitor 
M when x>0 and hence captures the value of x at that mo- 
ment Rule R replaces the existential quantifier. Eagle also 
provides a previous-time operator, which allows us to define 
past time operators, and a concatenation operator, which al- 
lows users to define interval based logics, and more. Data 
parametrization works uniformly for rules over past as well 
as future; this is non-trivial to achieve as the implementation 
doesn’t store the trace, see [5], 


2.1 Introducing Eagle 

2.1.1 Fundamental Concepts 

In most temporal logics, the formulas OF and OF satisfy 
the following equivalences: 

□F=FAO(DF) 0F = FVO(0F) 


2.12 Eagle Syntax 

A specification S comprises a declaration part D and an ob- 
server part O. D comprises zero or more rule definitions 
R, and O comprises zero or more monitor definitions M, 
which specify what is to be monitored. Rules and monitors 
are named ( N ). 


One can show that OF is a solution to the recursive equa- 
tion X = F A QX; in fact it is the maximal solution. A 
fundamental idea in our logic, EAGLE, is to support this 
kind of recursive definition, and to suable users define their 
own temporal combinators in such a fashion. In the current 
framework one can write the following definitions for the 
two combinators Always and Sometime; 

max Alwavsl Form F) = F A OAlways(F) 


S ::= DO 
D ::= R* 

O ::= M* 

R ::= { max I min } N(T, n 7i x n ) —F 

M ::= mon N = F 
T ::= Form | primitive type 

F ::= exp \ true j false | -F | Fj AF2 | Fj VF2 j F\ -* F 2 j 
OFjOF|F,-F 2 iJV(Fi,...,F n )|* I - 


min Some time ( Form F)=FV QSometime(F) 

First note that these rules are parameterized by an Eagle 
formula (of type Form). Thus, assuming an atomic for- 
mula, say jc < 0, then, in the context of these two defini- 
tions, we will be able to write Eagle formulas such as, 
Always(x > 0), or Always(Sometime(jc > 0)). Secondly, 
note that the Always operator is defined as maximal; when 
applied to a formula F it denotes the maximal solution to 
the equation X — F A QX. On the other hand, the Sometime 
operator is defined as a minimal, and Sometime(F) repre- 
sents the minimal solution to the equation X = F V OX. In 
EAGLE, this difference only becomes important when eval- 
uating formulas at the boundaries of a trace. 

Eagle has been designed specifically as a general pur- 
pose kernel temporal logic for run-time monitoring. So to 


A rule definition R is preceded by a keyword indicating 
whether the interpretation is maximal or minimal Param- 
eters are typed, and can either be a formula of type Form. 
or of a primitive type, such as int, long, float etc.. The 
body of a rule/monitor is a boolean- valued formula of the 
syntactic category Form. However, a monitor cannot have a 
recursive definition, that is, a monitor defined as mon N — F 
cannot use N in F. For rules we do not place such restric- 
tions. The propositions of this logic are boolean expres- 
sions over an observer state. Formulas are composed us- 
ing standard propositional connectives together with a next- 
state operator (OF), a previous-state operator (OF), and 
a concatenation-operator (F\ - Ff). Finally, rules can be ap- 
plied and their parameters must be type correct; formula 
arguments can be any formula, with the restriction that if an 
argument is an expression, it must be of boolean type. 
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2.1-3 EAGLE Semantics 


22 Linear Temporal Logic in Eagle 


The semantics of the logic is defined in terms of a satis- 
faction relation, \=, between execution traces and specifi- 
cations. We assume that an execution trace 0 is a finite 
sequence of program states G = sis 2 ...s„, where jct| = n 
is the length of the trace. The i’th state r, of a trace a is 
denoted by cr(i). The term denotes the sub-trace of cr 
from position i to position j, both positions included. Given 
a trace a and a specification D O, we define: 

a\^DO iff V (mon N = F) gO . o.l |=nf 

That is, a trace satisfies a specification if the trace, ob- 
served from position 1 (the first state), satisfies each mon- 
itored formula. The definition of the satisfaction relation 
| —d C {Trace x nat) x Form , for a set of rule definitions 
D , is presented below, where 0 < i < n 4- 1 for some trace 
cr — s\Si ...s n - Note that the position of a trace can become 
0 (before the first state) when going backwards, and can be- 
come n -(- 1 (after the last state) when going forwards, both 
cases causing rule applications to evaluate to either true if 
maximal or false if minimal, without considering the body 
of the rules at that point. 


o,i •=£) exp iff 1 < i < joj and eval(exp){o{i )) 
o, i i =d true 
a, i ftp false 

a,i'r=D~'F iffo,i^cF 

a,! j= D Fi Af? iff o , i f=o Fi and o,i po F 2 
op pd F\ V F 2 iff o, i '<=d F\ or o,i (=o F 2 
a,i ‘-=d F\ — t F 2 iff o,i \=o Fy implies <T,i j=o F 2 
Op' }=£i QF iff i < jo) and o,i'-|- 1 j=o F 
O ,i \=d QF iff 1 < i and 0,i — 1 F 
o,i j —d F\ ‘ F 2 iff 3 7 s.L i<j< |o| + 1 and 

a D j-tjp — D gjyj CT l/.l <J D j i t= D F 2 


o,i 


\= D N(F u ...,F m ) 

f if 1 < i 5; io| then: 


iff t 


0,1 \=dF\xi m- Fi,...,x m i-4 F m ] 
where (N(T\ x m ) =F) eD 

otherwise, if i = 0 or i = jo | + 1 then: 


( rule N is defined as max in D 


An atomic formula (exp) is evaluated in the current state, 
i, in case the position i is within the trace (1 < i < n); for 
the boundary cases ( i = 0 and i = n + 1) it evaluates to false. 
Propositional connectives have their usual semantics in all 
positions. A next-time formula QF evaluates to true if the 
current position is not beyond the last state and F holds 
in the next position. Dually for the previous-time formula. 
The concatenation formula F\ ■ F 2 is true if the trace o can 
be split into two sub-traces a = GiCTi, such that F\ is true 
on , observed from the current position i, and F 2 is true 
on 02 (ignoring Oj , and thereby limiting the scope of past 
time operators). Applying a rule within the trace (positions 
1 . . . n) consists of replacing the call with the right-hand side 
of the definition, substituting arguments for formal param- 
eters. At the boundaries (0 and n + 1) a rule application 
evaluates to true if and only if it is maximal. 


We have briefly seen how in Eagle one can define rules 
for the □ and 0 temporal operators for LTL. Here we com- 
plete an embedding of propositional LTL in Eagle and 
prove its semantic correspondence. Figure 1 gives the se- 
mantic definition of the since and until LTL temporal oper- 
ators over finite traces; the definitions of O and ©, and the 
propositional connectives, are as for EAGLE. We assume 
the usual collection of future and past linear-time temporal 
operators. 

0, i (= F[ 11 F 2 iff 

1 < * < N and 3b : i < i 2 < |o| and 0 , 1*2 f= F 2 and 

V i] : i < i\ < i 2 implies o, i\ j= F\ 

o,i\=F\ S F 2 iff 

1 < i < |o| and 3h : 1 < i 2 < i and a,i 2 j= F 2 and 

V i] : 1*2 < i\ < i implies 0 ,i] j= F\ 

with definitions 

0 F = true 11 F QF = true S F 

D F — —iQ^F EE — — iQ-iE 

Fi WF 2 =Fi 11 F 2 V DFi Fi ZF 2 =Fi S F 2 vCjF 1 


Figure 1 . Semantic definitions for LTL 

For each temporal operator, future and past, we define a cor- 
responding Eagle rule. The embedding is straightforward 
and requires little explanation. The future time operators 
give rise to the following set of rules: 

min Next (Form E) = QF 

max Always (Form E) = E A ©Always (E) 

min Sometirae (Form F) = EV QScmetime(F) 

min Unti 1 ( Form Ei . Form F 2 ) = E?V(Ei A0until(Ei,E2)) 

max Unless ( Form F, . Form F>) =F 2 y{Fi A0Unless(Ei,E2)) 

The past time operators of LTL give rise to the following 
rules. 

min Previous ( Form E) = ©E 
max AlwaysPastf Form E) = E A ©AlwaysPast(E)) 
min ScaaetimePasti Form E) = E VOSometimePast(E)) 
min Since( Form Ei . Form F 2 ) —F 2 \/ (F\ A ©Since(E],l^)) 
max Zince( Form Ei . Form E> I =F 2 V (Ei A©Zince(Ei,E 2 )) 

An Eagle context containing all of the above rules then 
enables any propositional LTL monitoring formula to be 
expressed as a monitoring formula in Eagle by mapping 
the LTL operators to the Eagle counterparts. Note that 
through simply combining the definitions for the future and 
past time LTLs defined above, we obtain a temporal logic 
over the future, present and past, in which one can freely 
intermix the future and past time modalities. 

Correctness of Embedding: 

To justify the above EaGLE definitions of LTL temporal 
operators, we can define an embedding function Embed : 
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LTL ~y Eagle that maps Q. F to Next(Embed(F)), □ F to 
A 1 ways [Embed (F)), etc., and then formally establish that 
cr, i 'f=LTL F iff a.i (=e a gle Embed{F) for all traces a and 
indices i. The proof follows by induction over the structure 
of the formula F; insufficient space allows for its inclusion, 
but see [4], 

3 Algorithm 

In this section, we now outline the computation mecha- 
nism used to determine whether a monitoring formula given 
in LTL holds for some given input sequence of events. The 
evaluation of a formula F on a state s = cr(i) in a trace o 
results in another formula eval(F,s) with the property that 
a, i j= F if and only if cr, i + 1 J= eval(F, s ) . The definition of 
the function eval : Form x State — Form uses another auxil- 
iary function update : Form x State -A Form . The role of the 
function update is to pre-evaluate a formula if it is guarded 
by a previous operator. Formally, update has the property 
that o, i f= QF iff o, i + 1 j= update(F. s ) . Had there been no 
past time modality in Eagle we could have ignored update 
and simply written o, i f= QF iff cr, i + 1 j= F. The value of 
a formula F at the end of a trace is given by value (F). The 
function value : Form — > { true , false } when applied on F re- 
turns true if F is satisfied at the end of the trace or in other 
words iff a, |a| + 1 F and returns false otherwise. Thus 
given a sequence of states s i S 2 . . . s„ , an LTL formula F writ- 
ten in Eagle is said to be satisfied by the sequence of states 
if and only if value(eval(...eval(eval(F,si),S 2 )...s n )) is 
true . The definition of the functions eval , update and value 
forms the calculus of the LTL subset of Eagle. 

3.1 Calculus 

The eval , update and value functions are defined a pri- 
ori for all operators, which is not possible for fully general 
Eagle [5]. We do not define the functions on the previous 
operator Q, since this operator is eliminated in the calcu- 
lus. The definition of eval, update and value on the different 
primitive Eagle operators is given in Figure 2. In the given 
definitions, op can be A, V, — k Note that eval of a formula 
of the form QF on a state s reduces to the update of F on 
state s. This ensures that if F contains any past time oper- 
ators then update of F updates them properly. Moreover, 
value {QF ) is false as the operator Q has a strong interpre- 
tation in Eagle. The value of a max rule is true and that of 
a min rule is false . 

value(R(Fi ,...,F„)) = true if R is max 

value(R(Fi,...,F„)) = false if R is min 

Future Time Operators 

Consider the Always operator: 

max Always ( Form F) = F A 0 A l wa y s (F) 


eval (true, si 

— 

true 

eval (false, s i 

= 

false 

eval{exp,s) 

= 

value of exp in s 

eval{F\ op F 2 ,s) 

= 

eval(F],s) op eval(F 2 ,s) 

eval(->F,s) 

= 

—eval(F,s) 

eval(QF,s) 

= 

update(F,s ) 

value (true) 

= 

true 

value (false 1 

= 

false 

value{exp ) 

= 

false 

value (Fi op F 2 ) 

= 

value{Fj ) op value{F 2 ) 

value {—•F) 

= 

- 1 value (F) 

value {QF) 

= 

false 

update (mie.s) 

= 

true 

update (false, si 

— 

false 

update(exp,s) 

= 

exp 

update (Fj op F 2 ,s ) 

= 

update(F\ , s) op update {F 2 ,s) 

update (—F,s) 

= 

~'updale{F,s) 

update{Q)F,s) 

= 

Qupdate(F,s ) 


Figure 2 . eval, value and update definitions 

For this rule eval and update are defined as follows. 

eval(Always(F),s) = eval{F AQhlways{F),s) 
update (Always (F),s) = Always{update(F,s)) 

Similarly we can give the calculus for the other future time 
LTL operators as follows: 

eval(Next(F),s) = eval(QF,s) 
update (Next (F) , s) =JJext (update(F,s)) 

eval(Soir.etiine(F),s) = eval(F V QSametitt!£(F),s) 
update(Satnetime(F),s) = Sometim e(update(F,s)) 

eval(Until(Fi,F2),s) = eval(F 2 V (Fi AQUntil(Fi,F2)),s) 
update (Unt i 1 {F \ , Fi ) , s ) = Unt i 1 ( update (F\ , s) , update (F> , s ) ) 

eval(t]nless(Fi,F 2 ),s) ■= eval{F2 V (Fi AO Un i ess (Fi,F2)),s) 
update (Unless (F) , F2 ) , s) = Unless ( update (Fi , s ) , update^, s)) 

Past Time Operators 

The past time LTL operators are defined in the form of rules 
containing a 0 operator. In general, if a rule contains a for- 
mula F guarded by a previous operator on its right hand side 
then we evaluate F at every event and use the result of this 
evaluation in the next state. Thus, the result of evaluating 
F must be stored in some temporary placeholder so that it 
can be used in the next state. To allocate a placeholder, we 
introduce, for every formula guarded by a previous opera- 
tor, an argument in the rule and use these arguments in the 
definition of eval and update for this rule. Let us illustrate 
this as follows. 

max Always Past ( Form F) — F A ©AlwaysPast(F) 
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For this rule we introduce another auxiliary rule 
AlwaysPast' that contains ah extra argument correspond- 
ing to the formula O AlwaysPast(F). In any LTL formula, 
we use this primed version of the rule instead of die original 
rule. 

AlwaysPast(F) = AlwaysPast'fF. true ) 
eva/(AiwaysPast'(F,posti ), s) = eval(F Apast u s) 
update(Alwa.ysPa.st'(F,past 1 ),s) = 

Aiway sr &st'(update(F,s),eval(Always'£‘&st , (F, past i),s)) 

Here, in eval, the subfotmula ©AlwaysPast(F) guarded 
by the previous operator is replaced by the argument past { 
that contains the evaluation of the subformula in the pre- 
vious state. In update we not only update the argument 
F but also evaluate the subformula Always Pas t'(F,paitj ) 
and pass it as second argument of AlwaysPast'. Thus in 
the next state past 1 is bound to ©AlwaysPast' (Fjpasfj). 
Note that in the definition of AlwaysPast' we pass true as 
the second argument This is because, AlwaysPast being 
defined a maximal operator, its previous value at the begin- 
ning of the trace is true . Similarly, we can give the calculus 
for the other past time LTL operators as follows: 

Previous(F) = Previcus'fF. false ) 
eval(Pr&vious\F,past 1 ),s) = eval(past 1 ,s) 
update (Pr evi ous' (F,past 1 ),s) = 

Previous ' (update(F,s),eval(F,s)) 

SometimePast(F) = SometimePast'lF. false) 
ava/(SometimePast'(F, /*!«!),£) = eval(F V past t ,s) 
update(Somezime?ast'(F,past 1 ),s) = 

SometimePa.st'(update(F,s),eval(ScmezimaPa.st'(F,past- l ),s)) 

Since(Fi , F2) — Since' (Fy , F?. false ) 
eva/(Since'(Fi,F2,pasrj),s) =evci{F% V ( F\ l\past{),s) 
updtite(Sincs'(Fi,F2,past 1 ),s ) = 

Since' (update(F\,s),update(Fi,s),eval(Since'(Fi,F2,[>asti),s)) 

ZincefFi.F’) = 2ince'(Fi,F>, true ) 
eval(Zir\ce’(Fi,F2,past l ),s) =eval(Fz V(Fj Apajti),s) 
update(Zince'(Fi,F2,pasti),s) = 
Zince'(update(F\,s),updale(Fi,s),eval(Zince'(F\,F2,past 1 ),s)) 

For the sake of completeness of the calculus we explicitly 
define value on the above LTL operators as follows: 

value (Always (F)) = va/u^AlwaysPast'^paff!)) 

= value (UniessfF^Fj)) = value(Zince'(Fi,F2,pusfi)) = true 

va/ne(Sometime(F)) = va/ue(SometimePast'(F,pasrj)) 

= valne(until(Fi,F 2 )) — value (Since.' {F\,F2, past \)) — false 

Note that in the above calculus we have eliminated the 
previous operator by introducing an auxiliary argument or 
placeholder for every formula guarded by the © operator. 
So, we can’t use the operator Q when writing an LTL for- 
mula; instead we use the rule Previous as defined above. 


Correctness of Evaluation 

Given a set of definitions of eval, update and value func- 
tions for the different operators of LTL, as detailed above. 


we claim that for a given sequence o = s\S2-..s n and an 
EAGLE embedded LTL formula F: 

o. 1 )=eagle F iff value(eval(. . . eval(eval(F,s\),S 2 ) ■ • .r n )). 

Insufficient space prohibits inclusion of the proof. 


4 Implementation and Complexity 


We have implemented in Java the Eagle monitoring 
framework. In order to make the implementation efficient 
we use the decision procedure of Hsiang [13]. The proce- 
dure reduces a tautological formula to the constant true, a 
false formula to the constant false, and all other formulas 
to canonical forms, each as an exclusive disjunction (©) of 
conjunctions. The procedure is given below using equations 
that are shown to be Church-Rosser and ter minatin g modulo 
associativity and commutativity. 


simplify: 

true A $ = <j> 

<j> A0 = <j> 
false ©0 = 0 
4©4 = false 
-4 = true ffi 4 


false A 4 = false 

4i V02 = (0i A42) © 4i ©42 

4i ->02 =true©4i ©(4i A4 2 ) 

4i 542 = tme©4i ©42 

4i a (42 ©4s) = (0i A42)©(4i A 43 ) 


In particular the equations 4 A 0 = 0 and 0 © 0 = false en- 
sures that, at the time of monitoring, we do not expand die 
formula beyond bound. The bound is given by the following 
theorem: 


Theorem 1 The size of the formula at any stage of moni- 
toring is bounded by 0(m 2 2 m logm), where m is the size of 
the initial LTL formula 0 for which we started monitoring. 

Proof The above set of equations, when regarded as 
simplification rules, keeps any LTL formula in a canoni- 
cal form, which is an exclusive disjunction of conjunctions, 
where the conjuncts are either propositions or subformulas 
having temporal operators at top.Moreover, after a series of 
applications of eval on the states Si,S 2 ,—,s n , the conjuncts 
in the normal form eval(. . .eval(eval(q>,si),S2) - ■ ■ ,s n ) ate 
propositions or subformulas of the initial formula 0, each 
having a temporal operator at its top. Since there are at 
most m such subformulas, it follows that there are at most 
2 m possibilities to combine them in a conjunction. The 
space requirement for a conjunction is O(mlogm), assum- 
ing that in the conjunction, instead of keeping the actual 
conjuncts, we keep a pointer to the conjuncts and assum- 
ing that each pointer takes O(logTw) bits. 1 Therefore, one 

'Every unique subfonnula having a temporal operator at the top in the 
original formula can give rise to several copies in the process of monitor- 
ing. For example, if we consider F\ = □ 0q after some steps, it may get 
converted to Fj = 0? A DO <?• In F 2 the two subfommlas 0q are essentially 
copies of 0q in Fi . It is easy to see all such copies at any stage of monitor- 
ing will be same. So we can keep a single copy of them and in the formula 
we use a pointer to point to that copy. 
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needs space 0(m2 m log m) to store the structure of any ex- 
clusive disjunction of such conjunctions. Now, we need 
to consider the storage requirements for each of the con- 
juncts that appears in the conjunction. Note that, if a con- 
junct contains a nested past time operator, the past { argu- 
ment of that operator can be a formula. However, instead 
of storing the actual formula at the argument past l we can 
have a pointer to the formula. Thus, each conjunct can 
take space up to O(mlogm). Hence space required by all 
the conjuncts is 0(m 2 logm). Now for each past operator 
we have a formula that is pointed to by the past l argu- 
ment and all those formulas by the above reasoning can 
take up space 0(m 2 2 m logrn). Hence the total space re- 
quirement is 0(mlogm2 m + m 2 logm + m 2 2 m logm), which 
is 0(rrr2 m logm). □ 

The implementation contains a strategy for the applica- 
tion of these equations that ensures that the time complexity 
of each step in monitoring is bounded. We next describe the 
strategy briefly. Since, our LTL formulas are exclusive dis- 
junction of conjunctions we can treat them as a tree of depth 
two: the root node at depth 0 representing the © operator, 
the children of the root at depth 1 representing the A op- 
erators, and the leaf nodes at depth 2 representing proposi- 
tions and subformulas having temporal operators at the top. 
The application of the eval function on a formula is done in 
depth- first fashion on this tree and we build up the resultant 
formula in a bottom-up fashion. At the leaves the applica- 
tion of eval results either in the evaluation of a proposition 
or the evaluation of a rule. The evaluation of a proposition 
returns either true or false. We assume that this evaluation 
takes unit time. On the other-hand, the evaluation of a rule 
may result in another formula in canonical form. The for- 
mula at any internal node (i.e. a A node or a © node) is then 
evaluated by taking the conjunction (or exclusive disjunc- 
tion) of the formulas of the children nodes as they get eval- 
uated and then simplifying them using the set of equations 
simplify . Note that the application of simplify on the 
conjunction of two formulas requires the application of the 
distributive equation 4 >i A (02 ©®3) = (hi A (fc) Q (©1 A $3) 
and possibly other equations. 

At any stage of this algorithm there are three formulas 
that are active: the original formula F on which eval is ap- 
plied, the formula F', and the result of the evaluation of 
tiie subformula Fsub. So, by theorem 1 we can say that the 
space complexity of this algorithm is 0(m 2 2 m logm). More- 
over, as the algorithm traverses the formula once at each 
node it can possibly spend 0(m 2 2 m logm) time to do the 
conjunction and exclusive disjunction. Hence the time com- 
plexity of the algorithm is 0(m 2 2 m \ogm) ■ 0(m 2 2 m logm) 
or 0(m 4 2 2m log 2 m). These two bounds are given as the fol- 
lowing theorem. 

Theorem 2 At any stage of monitoring the space and time 


complexity of the evaluation of the monitored LTL formula 
on the current state is 0(m 2 2 m logm) and 0(m 4 2 2m log 2 m) 
respectively. 

5 Examples and Experiments 

This section illustrates the use of Eagle on two 
concurrency-related applications - detection of deadlock 
potentials and testing of a real-time concurrent system. 

5.1 Using Eagle for Deadlock Detection 

We present an example that illustrates the use of EAGLE 
to detect a simple class of cyclic deadlocks. Specifically 
Eagle monitors an event stream of lock acquisitions and 
releases, and reports any cyclic lock dependencies. If there 
are two threads t\ and tz such that t\ takes lock h, and then 
prior to releasing / 1 , takes lock h, and furthermore if t 2 takes 
lock h, and then prior to releasing h, takes lock f, then 
there is a cyclic lock dependency that indicates the possi- 
bility of deadlock. This is a simplification of the general 
dining philosopher problem, restricted to cycles of length 
two. 

We present two implementations. One illustrates how 
Eagle integrates with Java, allowing one to intermix al- 
gorithms written in a general programming language with 
Eagle monitors. The other is a ’’pure” solution that just 
uses Eagle rules. Each solution utilizes the ability of 
Eagle to parameterize rules with data values as well as 
formulas. 

For both implementations the state observed by Eagle 
contains three integer variables that get updated each time a 
new lock or release event is sent to the observer. Let s be the 
object representing the observer state. The variable s . type 
is set to 1 if the event is a lock event and 2 if it is a release 
event, s . thread is an integer which uniquely identifies the 
thread and s . lock uniquely identifies the lock. For clar- 
ity we define predicates s . lock ( ) and s . release ( ! that 
test whether s . type is set to 1 or 2, respectively. We first 
present the pure solution. 

min Conf lict(int t ,int Zj ,int I2) = 

Vntil(-<(s.releaseQ Asthread = t A s.lock = If), 
s.lockQ A s thread = t A s.lock = Z] ) 
min Conf lictLock(mt t ,int l\ ,int If) = slockQ A 

sthread f t Aslock = h AContlict(s.tkread,li ,lf) 
min NestedLockZint r.intZ) = 

Until(->(s.reZeaje() As thread = t A s.lock = Z), 
s.lock() A sthread = t A s-lock l A 
(OSometime(ConflictLock(z, Z,s.Zock)) V 
OSometimePast(ConflictLock(r,Z,s-Zock)))) 
mon M = -iSametime(s.lock() A 

NeszeoLockf thread, s.lock)) 
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The intuition is that the Sometime in monitor M is satis- 
fied in a state where a lock is taken that is the ’’first” of the 
four locks in the pattern described above. The thread and 
the lock value of that lock are passed as data parameters to 
NesiedLock which ’’searches” for a subsequent lock taken 
by that thread prior to the release of the first lock. If such 
a second lock is found, it binds the data value of the sec- 
ond lock to a data parameter and searches both forward and 
backward through the trace with ConflictLock for a second 
thread that takes the two locks in reverse order. 

The second implementation uses a set data structure 
within the observer state that holds triples of values of the 
form [r, l \ , h] recording that thread t took nested locks l\ and 
then h- The predicate addTriple inserts such a triple into 
the set and evaluates to true if there is no conflicting triple 
in the set. A conflicting triple is one of the form \t 2 ,h-,h} 
for tz ^ t. 


max DiffLock(intf,int /) = s.lockQ Ns. thread = t As. lock l 
max CheckLockfint t ,int /) = s.lockQ Ns thread = t A 

s.lock l As.addTriple(t,l,s.lock ) 
max Reiease(int r,int l) = s.releaseQ A s. thread = t As.lock = l 
min NestedDiffLock(intr, inti) = 

Untii(-i Release^,/), DiffLock(r,i)) 
min NestecCheckLockfint r.int l) = 

Until(^Release(t,l),CheckLock(r,/)) 
mon M = Always ((s.lockQ ANestedDifiLock(sJhread,sJock)) 
— >■ NeszedCheckLock(s.thread,s.lock) 


(block 
:id P 


i 


:Eode-iist ( 

(task 
:id T1 

: start-temporal-conditicns 
rend-teiporal-conditions ( 
i 

(task 
: id T2 

: starc-tenrooral-coscitions 

) 

) 


(( P start (1 5) i ) 
T1 start (1 30) ) ) 


( ( T1 end (10 20! i S 


Figure 3. Example plan 


are supposed to be executed sequentially in the given order. 
The plan specifies that T1 should start 1-5 seconds after P 
starts and should end 1-30 seconds after Ti starts. Task T2 
should start 10-20 seconds after Tl ends. The controller has 
been hand-instrumented in a few places to generate an exe- 
cution trace when executed. An example execution trace of 
the plan in Figure 3 is presented below: 

start P 397 
start Tl 1407 
success Tl 2440 
start T2 14070 
success T2 15200 
success P 15360 


The monitor identifies a first lock and the rule Nested- 
DiffLock returns true if a second, nested, lock is taken. If 
so, NestedCheckLock adds the triple to die set and returns 
false if a conflict exists. 

5.2 Testing a Planetary Rover 

The Eagle logic has been applied in the testing of a 
planetary rover controller, as part of an ongoing collabora- 
tive effort with other colleagues (see [2]) to create a fully 
automated test-case generation and execution environment 
for this application. The controller consists of 35,000 lines 
of C++ code and is implemented as a multi-threaded sys- 
tem, where synchronization between threads is performed 
through shared variables, mutexes and condition variables. 
The controller operates a rover, named K9, which essen- 
tially is a small car/robot on wheels. K9 itself is a prototype, 
and serves to form the basis of experiments with rover mis- 
sions on Mars. The controller executes plans given as input 
A plan is a tree-like structure of actions and sub-actions. 
The leaf-actions control the rover hardware components. 
Each action is optionally associated with time constraints 
indicating when it should start and when it should termi- 
nate. Figure 3 presents an example input plan. The plan 
is named P and consists of two sub-tasks Tl and T2, which 


In addition to information about start and (successful or fail- 
ing) termination, each event in the trace is associated with 
a time-stamp in milliseconds since the start if the applica- 
tion. The testing environment, named X9 (explorer of K9), 
contains a test-case generator, that automatically generates 
input plans for the controller from a gr ammar describing 
the structure of plans. A model checker extended with sym- 
bolic execution is used to generate the plans [14]. Addi- 
tionally, for each input plan a set of temporal formulas is 
generated, that the execution trace obtained by executing 
that plan should satisfy. The controller is executed on each 
generated plan, and the implementation of Eagle is used 
to monitor that the generated execution trace satisfies the 
formulas generated for that particular plan. The properties 
generated for the plan in Figure 3 are presented in Figure 4, 
and should be self-explainable. 

X9 was evaluated by seeding errors in the rover con- 
troller. One error had to do with the closeness in time be- 
tween termination of one task and the start of the succes- 
sor. If a task Ti ended in a particular time range (after the 
start time of the successor Tz), then task Tz would wrongly 
fail rather than execute. R unnin g X9 detected this prob- 
lem immediately. Note that the property violated was bi- 
nary/propositional in nature: a task failed that should have 
succeeded. 
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H30H MO — SuEtstinifi { {s. start ( *P* } } ' - 
mon Ml = Always ( {s . start { * F" } } -> 

( Sometinie { {s . success ("?*)} 

\/ {s.faii {*?*}}} )) ♦ 
men M2 = Always ( {s. start ( "P* ) > -> 

Sometime ({ s.s tart {"Tl") }} ) . 
man M3 = Always { {s. success { "T2 ")}-> 

S ometime({s. success { "P* ) }) ) } . 
mon M4 = Always { (s . start { *T1 * ) .} -> 

(Sometime ({s. success (•Tl* ) } } 

\/ Sometime ({s.f ail ( "Tl) })) ) . 
mon MS = Always ( {s. fail ("Tl" ) } -> 

not Sametime({s.start("T2") } ) ) • 
mon M6 = Always ( {s. success ("Tl*) } -> 

Sometime ({s.s tart { *T2" )}) } . 
mon M7 = Always {{s- start (*T2*)} -> 

(Sometime ( {s .success ( *T2* ) } 

\/ {s.faiiPT2'}})}) . 

Figure 4. Generated properties 

Eagle allows for the formulation of real-time properties 
that take the time stamps into account Such an experiment 
is mentioned in [5], In that experiment a real unknown bug 
was located. It was discovered that the application did not 
check lower bounds on durations, whereas it should. That 
is, if a task finished before it was supposed to, the task 
should fail, but it wrongly succeeded. The bug was not im- 
mediately corrected, and later showed up during a field test 
of the rover. 

6 Conclusion and Future Work 

We have presented a representation of linear tempo- 
ral logic with both past and future temporal operators in 
Eagle. We have shown how the generalized monitoring al- 
gorithm for Eagle becomes simple and elegant for this par- 
ticular case. We have bounded the space and time complex- 
ity of this specialized algorithm and thus showed that gen- 
eral LTL monitoring is space efficient if we use the Eagle 
framework. Initial experiments have been successful. Fu- 
ture work includes: optimizing the current implementation 
and investigating other efficient subsets of Eagle. 
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